PC MEMORY CARD INTERNATIONAL ASSOCIATION (PCMCIA) README
_________________________________________________________

   This file contains a brief description of the
   PCMCIA architecture as it applies to the OS/2*
   operating system.  Also included is a list of
   supported functions and information on
   deviations from the PCMCIA standard.


OVERVIEW
________

   The Personal Computer Memory Card International
   Association (PCMCIA) is an organization of
   computer hardware and software manufacturers
   that is developing industry standards for
   personal computer memory card architecture. The
   PCMCIA standards include specifications for
   both the hardware and software components of
   the technology.


PCMCIA HARDWARE

   There are three major hardware components
   defined in the PCMCIA architecture:  Cards,
   Sockets, and Adapters.

   The cards come in several standardized sizes
   (referred to as form factors). The basic form
   factor is very similar to a credit card.  There
   is a wide range of potential applications for
   PCMCIA cards, including:

   o   Connectivity devices, such as modems, local
       area networks, 3270 terminal emulators, or
       FAXes

   o   Secondary storage devices, such as 1.8 inch
       rotating hard disks or solid state file
       disks

   o   Random access memory, such as Flash, SVRAM,
       or NVRAM memory

   o   Software, such as applications, device
       drivers, or ROM extensions

   PCMCIA cards are treated in much the same way
   as standard removable media (such as
   diskettes).  The card slots (called sockets)
   are open bays which the cards are inserted into
   without removing system covers or powering off
   the system unit.  Each socket may or may not
   have latches, levers, locks, or even
   motor-mount assistance (much the same as
   features for diskette technology).

   Adapters are connected to the host system's
   bus. The adapters map the host system bus
   technology to the PCMCIA technology.  According
   to PCMCIA standards, up to 256 adapters can
   exist on a host system, and each adapter can
   have a maximum of 16 sockets.


PCMCIA SOFTWARE

   There are three major software components
   defined in the PCMCIA architecture:  Clients,
   Card Services, and Socket Services.

   Clients manage the device characteristics in an
   operating-system-specific environment and can
   be generalized as card-specific device drivers.
   Therefore, for any given card (device) there
   must be specific device driver for each
   supported operating system.  In addition, one
   client device driver can simultaneously
   manipulate several cards of the same type.
   Clients rely on the Card Services interfaces in
   order to set up and remove accessibility to the
   PCMCIA cards (devices). The functions,
   features, and availability of client device
   drivers is the responsibility of the PCMCIA
   card developer/manufacturer.

   The Card Services component is an
   operating-system-specific layer that provides
   the Card Services functions defined in the
   PCMCIA interface specification.  The Card
   Services interface functions are provided
   according to the operating system's details for
   the client device driver model environment.
   Card Services relies on operating system and
   Socket Services interfaces in order facilitate
   requests from PCMCIA clients.  The functions,
   features, and availability of the Card Services
   component is the responsibility of the
   operating system developer/manufacturer.

   The Socket Services component is a
   hardware-specific layer that isolates the
   details of the adapter and socket logic from
   the other software components.  The Socket
   Services component provides the functions
   defined in the PCMCIA interface specification.
   Ideally, this software layer is built as a BIOS
   extension so that a single implementation can
   service multiple operating systems.  However,
   it is acceptable to have device driver
   versions, since several situations preclude the
   availability of ROM solutions (as would be the
   case when you are adding adapters into existing
   host systems).  The functions, features, and
   availability of the Socket Services component
   is the responsibility of the hardware (adapter
   option or system unit) developer/manufacturer.


PCMCIA SPECIFICATIONS

   The PCMCIA General Committee publishes the
   following specifications for the software
   architecture components:

       PCMCIA Card Services Release 2.00 Interface
       Specification

       PCMCIA Socket Services Release 2.00
       Interface Specification

   These specifications contain a complete
   description of the Card Services and Socket
   Services functions mentioned in this file.
   They are available publicly and can be ordered
   from:

     PCMCIA Office
     1030G East Duane Avenue
     Sunnyvale, CA 94086

     (408) 720-0107 Voice
     (408) 720-9416 Fax
     (408) 720-9388 BBS


OS/2 PCMCIA ARCHITECTURE
________________________

   As described earlier, in the OVERVIEW, there
   are six main components in the PCMCIA
   Architecture, three hardware components and
   three software components.  The focus in the
   OS/2 operating system is on the Card Services
   component and the changes introduced to the
   device driver model to provide the PCMCIA
   client device driver support.  There are three
   separate client environments in the OS/2
   operating system:  DOS, WIN-OS/2*, and the OS/2
   environment.  Each of these client environments
   has a separate Card Services interface binding,
   or protocol, which encapsulates the Card
   Service functions into the native environment's
   characteristics.  Though the OS/2 operating
   system supports these three application
   environments, it does not currently support the
   PCMCIA client interfaces in all environments.

   The responsibilities and restrictions in
   providing support of these client environments
   can be summarized as follows:

   1.  OS/2 Card Services is responsible for
       providing the client environment
       interfaces.

       Currently this support is limited to native
       OS/2 device driver environment for OS/2
       physical device drivers. The interface
       bindings for this support are defined in
       OS/2 PCMCIA CLIENT INTERFACES, later in
       this file.

       The architecture is designed in such a way
       that the PCMCIA software components mask
       the hardware details from the OS/2
       application environments.  There is no
       concept in the OS/2 operating system of a
       PCMCIA-aware application.

       The DOS client environment is not
       supported.  This means that the DOS PCMCIA
       interfaces, INT 1AH functions in the range
       of 80H - AFH, are intercepted and rejected
       with the Carry Flag set (value = 1).

       The WIN-OS/2 client environment is not
       supported.

   2.  OS/2 PCMCIA clients are responsible for
       providing device-specific support in the
       desired application environments.

       OS/2 PCMCIA clients can be written as stand
       alone physical device drivers or as
       physical/virtual device driver pairs. If
       the desired client device support is
       limited to OS/2 application environments,
       the client can be a single physical device
       driver.  If the desired application
       environments include DOS and/or WIN-OS/2
       then a virtual device driver must also be
       provided to emulate the device
       characteristics in those environments.


OS/2 INITIALIZATION ARCHITECTURE

   The following steps describe the initialization
   flow of the PCMCIA software components in the
   OS/2 operating system.  For best results, the
   statements placed in the CONFIG.SYS file should
   be ordered to support this flow.

   1.  Card Services Initialization

       The Card Services component is implemented
       as an installable physical device driver.
       Card Services manages resources (I/O
       address space, IRQs, and memory) across the
       set of installed client device drivers and
       Socket Services. Card Services assumes that
       a default set of resources is available
       when it is initialized and then adjusts the
       resource information (see next step) to
       limit or expand this resource base. The
       base set of resources that Card Services
       assumes are available to be managed is
       defined as follows:

       o   Non-system memory in the range
           C0000H-DFFFFH
       o   IRQs in the range 2-15
       o   I/O Addresses in the range 0108H-FFFFH,
           with the following exceptions:
           -   Addresses 3B4H, 3B5H, 3BAH, 3BBH,
               and 3C0H-3DFH are reserved for
               video use.
           -   Addresses 3F0H-3F7H are reserved
               for disk use.

   2.  Resource Map Initialization

       The Resource Map utility is a special
       client device driver that determines the
       current system's hardware resource pool.
       This client is a hardware-specific device
       driver that performs the resource pool
       determination in a hardware-specific
       manner.  The Resource Map utility
       determines the system's resource
       information and informs Card Services via
       the AdjustResourceInfo (35H) function
       during INIT_COMPLETE (1FH) command
       processing.  If an incorrect or no Resource
       Map utility is loaded, Card Services
       continues to run, managing the default set
       of resources it assumed were present (see
       previous step).  Since the Resource Map
       utility is hardware specific, it is
       provided by the hardware manufacturer on
       either the system's Reference Disk or
       Option's Reference Disk.

   3.  Socket Services initialization

       a.  One or more Socket Services device
           drivers can be loaded into the
           operating system to support the
           adapters in the system unit.  As each
           Socket Services device driver loads, it
           must verify the required hardware
           dependencies.  During the INIT_COMPLETE
           command (1FH) processing, Socket
           Services device drivers must complete
           their Inter-Device Communication (IDC)
           initialization processing by calling
           the AttachDD Device Helper (DevHlp)
           function.  If Card Services is loaded
           (as we are assuming in this scenario)
           the request for an IDC entry point for
           the device driver name "PCMCIA$ "
           (PCMCIA$ followed by a blank space)
           returns the 16:16 protect mode
           information.  The Socket Services
           device drivers then call the Card
           Services AddSocketServices (32H)
           function to establish the bidirectional
           IDC interface links.  If the AttachDD
           request fails, the Socket Services
           device driver must free any allocated
           resources and permit itself to be
           swapped out of the active system memory
           as needed.

       b.  Card Services processes the
           AddSocketServices (32H) function by:

           1)  Identifying the Socket Services
               resources required,

                   Card Services uses the
                   following Socket Services
                   functions to determine setup
                   resources: GetSetSSAddr (A0H),
                   GetSSInfo (83H), InquireAdapter
                   (84H), GetAdapter (85H),
                   InquireSocket (8CH), and
                   GetSocket (8DH).

           2)  Allocating resources from the
               resource map for Socket Services,

                   Card Services assigns
                   resources, if available, for
                   the new Socket Services
                   support.

           3)  Installing interrupt handlers for
               the Socket Services hardware,

                   Card Services uses the SetIRQ
                   DevHlp function to establish
                   the adapter specific interrupt
                   handling routine for each
                   adapter supported by the Socket
                   Services currently
                   initializing.

           4)  Programming the Socket Services
               hardware for the allocated
               resources.

                   Card Services uses the
                   following Socket Services
                   functions to activate the
                   adapter hardware: SetAdapter
                   (86H), SetSocket (8EH).

   4.  Client Device Driver Initialization

       Zero or more client device drivers can be
       loaded into the operating system to support
       the various cards that might be plugged
       into the system's PCMCIA sockets.  The
       initialization processing for these PCMCIA
       client device drivers is minimal.  The card
       must be initialized on an as-needed basis
       since a card can be inserted into a socket
       at any time.  To be ready for such events,
       the client device driver must establish an
       IDC interface connection into Card
       Services.  The IDC link is established
       during the INIT_COMPLETE command (1FH)
       processing, by using the AttachDD DevHlp
       function.  If Card Services is loaded (as
       we are assuming in this scenario) the
       request for an IDC entry point for the
       device driver name "PCMCIA$ " (PCMCIA$
       followed by a blank space) returns the
       16:16 protect mode information.  If the
       AttachDD request fails, the client device
       driver must enter a dormant state
       equivalent to the wait state that would be
       entered when a card is not present.  Once
       the presence of Card Services is confirmed,
       and the interface address is retrieved, the
       client device driver issues the
       RegisterClient request and enters the
       normal mode of event processing.

   Note:  Initialization ordering in CONFIG.SYS
          may play an important role in the
          following cases:

          1.  Steps 2, 3, and 4 could occur in any
              order, which means resource
              constraints may prevent certain
              Socket Services or client device
              drivers from being loaded properly.

          2.  Steps 3 and 4 could occur in any
              order and could be intermixed.
              Therefore, a client device driver
              must be sensitive to changes in the
              Socket Services support with respect
              to the number of sockets available.
              The SS_UPDATED event is used to flag
              these conditions.

          3.  The INIT_COMPLETE (1FH) device
              driver command is issued to device
              drivers in reverse order of the
              DEVICE= statements in the CONFIG.SYS
              file.


OS/2 PCMCIA CLIENT DEVICE DRIVER MODEL

   The client device driver model is an important
   element of the OS/2 PCMCIA architecture.  The
   PCMCIA client device driver model is a more
   restricted form of the general OS/2 device
   driver model.  All OS/2 PCMCIA client device
   drivers are loaded during operating system
   startup.  Therefore, before PCMCIA devices can
   be used, the user must determine the types of
   PCMCIA cards that might be used with the
   system, install the associated client device
   drivers, and add the appropriate statements to
   the CONFIG.SYS file.  It is recommended that
   client device drivers be installed using the
   OS/2 DDINSTAL utility;  this utility greatly
   simplifies the end user's installation task.

   The OS/2 PCMCIA client device driver model
   utilizes the multi-segment support available in
   the OS/2 operating system.  Whenever, a client
   device driver is not active (that is, no card
   is present) it should unlock its
   swappable/relocatable segments.  Furthermore,
   the single, nonswappable/nonrelocatable, base
   code segment must be organized in such a way
   that it contains all of the public entry points
   externalized by the client.  In this manner,
   all client public addresses are guaranteed
   valid.  For instance, the client device driver
   should ensure that the strategy, interrupt,
   Card Services callback, and other optional IDC
   entry point handling routines reside in the
   single, base code segment.  All worker routines
   should be placed in additional code segments,
   which should be further organized for optimal
   paging.  These additional code segments should
   be organized to contain routines that are used
   with roughly the same frequency intervals and
   conditions.

   All resources required by a client must be
   requested from the operating system or Card
   Services after the notification of card
   presence (through a CARD_INSERTION event), and
   after all the needed unlocked segments have
   been reestablished in the system memory space.

   Since it is possible to have numerous inactive
   client device drivers loaded in operating
   system, the potential savings in unused system
   memory space is substantial.

   Note:  The discussions above on the OS/2
          multi-segmented device driver model and
          the DDINSTAL utility are also applicable
          for device driver implementations of
          Socket Services.

   For further details on the OS/2 multi-segmented
   device driver model, refer to the OS/2 2.0
   Physical Device Driver Reference Manual.


EVENT PROCESSING FLOW

   In this section, a generalized event processing
   flow is described for definition of
   responsibilities within the OS/2 PCMCIA
   environment.  The following steps are provided
   for the CARD_INSERTION and CARD_REMOVAL events
   at a simplified level of discussion.

   1.  Hardware Interrupt (Adapter)

       a.  The end user inserts a PCMCIA Card into
           a socket. The adapter raises a Status
           Change interrupt to Card Services. Card
           Services, which has installed interrupt
           handlers for each adapter, calls the
           Socket Services AcknowledgeInterrupt
           (9EH) function to get the socket ID
           that generated the interrupt. Card
           Services sets up a timer handler to
           process the interrupt, issues the EOI
           for the adapter IRQ, and returns from
           the interrupt.

   2.  CARD_INSERTION Events

       a.  When the Card Services timer handler
           gets control, it processes the pending
           interrupt information by calling the
           Socket Services GetStatus (8FH),
           GetSocket (8DH), and SetSocket (8EH)
           functions to retrieve the specific
           interrupt meaning. In this scenario,
           the CardState and SocketState field
           values indicate a card insertion.
           Therefore, the Card Services timer
           handler creates CARD_INSERTION events
           and sends them to all client device
           drivers registered for the affected
           socket.

       b.  Each client device driver registered
           for the socket receives a
           CARD_INSERTION event notification.
           Client device drivers process the event
           by calling the Card Services
           GetConfigurationInfo (04H) function to
           determine if the card has been claimed
           by another client and with what
           attributes. The client may also elect
           to query more card data from the Card
           Information Structure (CIS) tuples. The
           client achieves this by using the Card
           Services GetFirstTuple (07H),
           GetNextTuple (0AH), and GetTupleData
           (0DH) functions.  If the client
           determines the card can not be
           supported, it returns from the event
           notification.  If the client determines
           the card can be supported, it uses the
           Card Services RequestIO (1FH),
           RequestIRQ (20H), and
           RequestConfigurationn (30H) functions
           to allocate resources to manage the
           card. If the resources are not
           available, the client returns from the
           event notification. If the resources
           are available, the client issues a
           SetIRQ DevHlp request to hook its
           interrupt handler into the operating
           system's IRQ chain.

           Note:  Clients may receive two event
           notifications if the local and global
           event masks both have CARD_INSERTION
           events selected via the Card Services
           RegisterClient (10H) and SetEventMask
           (31H) functions.

       c.  Card Services processes the
           RequestConfiguration (30H) function by
           calling Socket Services to program the
           adapter/card to the configuration
           information that has been locked for
           that socket.  Card Services uses the
           Socket Services SetSocket (8EH)
           function to achieve this.

   3.  Normal device activity

       a.  The client device driver uses the
           card-configured resources to perform
           normal device-specific manipulations,
           such as reading and writing data,
           processing device interrupts, enacting
           device commands, and so on.

   4.  Hardware Interrupt (Adapter)

       a.  The end user removes a PCMCIA Card from
           a socket. The adapter raises a Status
           Change interrupt to Card Services. Card
           Services calls the Socket Services
           AcknowledgeInterrupt (9EH) function to
           get the socket ID that generated the
           interrupt. Card Services sets up the
           interrupt processing timer handler,
           issues the EOI for the adapter IRQ, and
           returns from the interrupt.

   5.  CARD_REMOVAL Events

       a.  When the Card Services timer handler
           gets control, it processes the pending
           interrupt information by calling the
           Socket Services GetStatus (8FH),
           GetSocket (8DH), and SetSocket (8EH)
           functions to retrieve the specific
           interrupt meaning. In this scenario,
           the CardState and SocketState field
           values indicate a card removal.
           Therefore, the Card Services timer
           handler creates CARD_REMOVAL events and
           sends them to all client device drivers
           registered for the affected socket.

       b.  Each client device driver registered
           for the socket receives a CARD_REMOVAL
           event notification. Client device
           drivers process the event by releasing
           Card Services resources (for example,
           by calling the Card Services
           ReleaseConfiguration (1EH), ReleaseIO
           (1BH), and ReleaseIRQ (1CH) functions).
           In addition, the client device driver
           releases system resources (for example,
           by calling the UnsetIRQ DevHlp
           function).

       c.  Card Services processes the
           ReleaseConfiguration request by calling
           Socket Services to reprogram the socket
           so that it stops generating interrupts
           and cannot be accessed through the
           previously configured I/O addresses.
           Card Services uses the Socket Services
           SetSocket (8EH) function to achieve
           this.

       d.  Card Services processes the ReleaseIO
           (1BH) and ReleaseIRQ (1CH) functions by
           returning the referenced resources to
           the resource map.  This makes them
           available for subsequent request
           function calls.

   Note:  The previous scenario has been
          simplified for discussion purposes.  In
          addition, the defined scenario
          represents only the actions used to
          manage I/O card support.  There are
          numerous combinations of Card Services
          and Socket Services functions, as well
          as ordering differences, when this
          scenario is broadened to include other
          events.


IMPLEMENTATION LIMITATIONS AND RESTRICTIONS

   There are some restrictions on OS/2 PCMCIA
   client device drivers.  These restrictions are
   listed below:

   o   A maximum of 4 adapters can be supported by
       Card Services.

   o   A maximum of 8 sockets can be supported by
       Card Services.

   o   A maximum of 16 clients can be supported by
       Card Services.

   o   A maximum of 7 windows per socket can be
       supported by Card Services. The maximum
       window count is further defined such that 5
       are memory windows (4 for clients and 1 for
       Card Services), and 2 are I/O windows.

   o   No power management support is provided by
       Card Services.  For interfaces that have
       power management definitions, the values
       are ignored by Card Services.

   o   The following additional restrictions apply
       to client device drivers which manage
       PCMCIA cards with secondary storage
       devices:

       -   During device driver initialization the
           PCMCIA secondary storage card might not
           be present, but the device driver must
           still claim the required number of
           drive letters that it supports.

       -   Multi-partitioned cards must have a
           drive letter assigned to each partition
           for the partition to be accessible.

       -   All secondary storage cards are treated
           as removable media.  This prohibits
           enhanced performance from file systems
           using cached support.

   o   Memory Technology Drivers (MTDs) and media
       access routines are not supported.
       Therefore, the only memory cards supported
       in the OS/2 operating system are those that
       provide IDE, ATA, and ST506 interfaces.
       For the same reason, it is not possible to
       write generic OS/2 Flash File Systems.


OS/2 PCMCIA CLIENT INTERFACES
_____________________________

   The PCMCIA Card Services architecture has
   several basic elements in the interface
   description. These interface elements are
   necessary for generating a composite binding
   for client device driver developers.  The
   binding itself provides bidirectional
   validation of the PCMCIA architecture and the
   operating system implementation. These basic
   interface elements are:

   o   Functions
   o   Callbacks
   o   Events
   o   Memory Technology Drivers (MTD) Helpers
   o   Media Access Routines
   o   Return Codes.

   OS/2-specific descriptions for each of these
   elements are provided in the following
   sections.


FUNCTIONS

   The OS/2 operating system supports the
   following PCMCIA Card Services functions.

   o   AddSocketServices (32H)
   o   AdjustResourceInfo (35H)
   o   DeregisterClient (02H)
   o   GetCardServicesInfo (0BH)
   o   GetConfigurationInfo (04H)
   o   GetEventMask (2EH)
   o   GetFirstTuple (07H)
   o   GetNextTuple (0AH)
   o   GetStatus (0CH)
   o   GetTupleData (0DH)
   o   MapMemPage (14H)
   o   ModifyConfiguration (27H)
   o   ModifyWindow (17H)
   o   RegisterClient (10H)
   o   ReleaseConfiguration (1EH)
   o   ReleaseIO (1BH)
   o   ReleaseIRQ (1CH)
   o   ReleaseSocketMask (2FH)
   o   ReleaseWindow (1DH)
   o   RequestConfiguration (30H)
   o   RequestIO (1FH)
   o   RequestIRQ (20H)
   o   RequestSocketMask (22H)
   o   RequestWindow (21H)
   o   ResetCard (11H)
   o   SetEventMask (31H)
   o   ValidateCIS (2BH)

   Refer to PCMCIA Card Services Release 2.00
   Interface Specification for a complete
   description of each function.

   The PCMCIA Card Services function notation is
   defined for the OS/2 operating system as a
   register-based interface with the following
   register-to-argument assignments:

     On Input:

       [AL]            = Function argument
       [AH]            = Static value, hex AF
       [DX]            = Handle argument
       [DI]:[SI]       = Pointer argument
       [CX]            = ArgLength argument
       [ES]:[BX]       = ArgPointer argument

       All other registers are undefined.

     On Output:

       [AX]            = Status argument
       Carry Flag      = Completion flag

     All other registers are preserved.

   Card Services is invoked using the protect mode
   IDC entry point information returned by the
   AttachDD DevHlp function.  The caller must do
   the following.

   o   Operate in a FAR call/return model.

   o   Use only Global Descriptor Table (GDT)
       Level 0, 16:16 (Selector:Offset) addresses
       in all pointer or address fields referenced
       across the interface.

   o   Ensure that an appropriate stack is used
       for the calling model (16-bit protect mode)
       with at least 512 bytes of stack space
       available.

   o   Establish the Card Services DS register
       value (from the information returned by
       AttachDD) prior to issuing Card Services
       function requests.

   The PCMCIA Card Services architecture divides
   the interface functions into groups that
   represent a loose definition of client types.
   The groups of client functions defined in
   PCMCIA Card Services Release 2.00 Interface
   Specification are:

   o   Client Services
   o   Resource Management
   o   Bulk Memory Services
   o   Client Utilities
   o   Advanced Client Services.

   Support in the OS/2 operating system
   concentrates on the interfaces in the Client
   Services and Resource Management Interface
   groupings.  Functions not supported are
   returned with the standard Card Services
   UNSUPPORTED_FUNCTION error code (15H).


CALLBACKS

   Card Services callbacks are groupings of events
   into logical subsets which include a general
   description and common call-based argument
   usage conventions. The callback types received
   by a client device driver depend on the
   functions it uses.

   The OS/2 operating system supports the
   following PCMCIA Card Services callback types:

   o   Insertion
   o   Registration
   o   Status Change
   o   Reset
   o   Socket Services Updates

   The PCMCIA Card Services callback invocation
   notation is defined for the OS/2 operating
   system as a register-based interface, in a FAR
   call/return model, with the following
   register-to-argument assignments:

     On Input:

       [AL]            = Function argument
       [CX]            = Socket argument
       [DH]            = Information, socket status
       [DL]            = Information, card status
       [DI]            = ClientVal field from ClientData structure
       [DS]            = ClientDS field from ClientData structure
       [SI]            = ClientOff field from ClientData structure
       [ES]:[BX]       = Buffer argument
       [BX]            = Miscellaneous Argument, when no buffer argument

     All other registers are undefined.


     On Output:

       [AX]            = Status argument
       Carry Flag      = Completion flag

       All other registers are preserved.

   The ClientData structure is used in the
   RegisterClient function and has the following
   format.

        Field Name    Type      Description
        ----------    ------    --------------------------------
        ClientVal     USHORT    Client-specific data value
        ClientDS      USHORT    Client's data segment selector
        ClientOff     USHORT    Client's callback data offset
        Reserved      USHORT    Reserved field


EVENTS

   The OS/2 operating system supports the
   following PCMCIA Card Services events:

   o   BATTERY_DEAD (01H)
       Note:  This event can be generated at
              CARD_INSERTION time if hardware
              detection capabilities are
              available.

   o   BATTERY_LOW (02H)
       Note:  This event can be generated at
              CARD_INSERTION time if hardware
              detection capabilities are
              available.

   o   CARD_INSERTION (40H)

   o   CARD_INSERTION (40H) Artificial
       Note:  Support is limited to the
              RegisterClient function.

   o   CARD_READY (04H)

   o   CARD_REMOVAL (05H)

   o   CARD_RESET (11H)

   o   REGISTRATION_COMPLETE (82H)

   o   RESET_COMPLETE (80H)

   o   RESET_PHYSICAL (0FH)

   o   RESET_REQUEST (10H)

   o   SS_UPDATED (16H)
       Note:  Support is limited to the
              AddSocketServices function.

   The events received by a client device driver
   depends on the functions it uses.


MEMORY TECHNOLOGY DRIVER (MTD) HELPERS

   The Memory Technology Driver (MTD) helper
   routines provide Card Services assistance to
   MTDs during Read, Write, and Erase operations.
   The OS/2 operating system does not support
   PCMCIA Memory Technology Drivers.  Therefore,
   all MTD-related support--including MTD
   helpers--is not supported.


MEDIA ACCESS ROUTINES

   The media access routines are the common worker
   routines that are used by MTDs to perform the
   low-level primitives underlying the basic Read,
   Write, and Erase operations.  The OS/2
   operating system does not support PCMCIA Memory
   Technology Drivers. Therefore, all MTD-related
   support--including media access routines--is
   not supported.


RETURN CODES

   All return codes are used and returned in the
   manner defined in the PCMCIA Card Services
   Release 2.00 Interface Specification unless
   explicitly noted in this document.  Function
   compatibility determines which of the return
   codes (equate names and numeric value) will
   actually be returned for each function.

   Functions that are not supported will be
   returned with the standard Card Services
   UNSUPPORTED_FUNCTION error code (15H).


CARD SERVICES 2.00 FUNCTION DEVIATIONS
______________________________________

   There are some deviations from the PCMCIA Card
   Services Release 2.00 Interface Specification
   in the OS/2 operating systems PCMCIA support.
   These deviations are noted below.

   o   General

       The following return codes are available on
       all Card Services functions supported by
       the OS/2 operating system.

       Return Codes:

       BUSY                        Unable to
                                   process request
                                   at this time;
                                   retry later.

                                   The calling
                                   client is
                                   expected to
                                   retry the
                                   failed
                                   operation at a
                                   later time.

       OUT_OF_RESOURCE             Out of internal
                                   or system
                                   resources
                                   necessary to
                                   process the
                                   request.

                                   The calling
                                   client is
                                   expected to
                                   either retry
                                   the operation
                                   later, or
                                   cancel the
                                   current
                                   operation.

   o   AddSocketServices (32H)

       The Attributes field defines details for
       the new Socket Services entry point. Card
       Services accepts only bit 1--16:16 protect
       mode requests.

       The DataPointer field is used to establish
       data addressability for Socket Services
       when called by Card Services.  Card
       Services accepts only 16-bit, protect mode,
       GDT Level 0, data selector values.

       Return Codes:

       OS/2 Card Services returns the following
       error codes in addition to the error codes
       defined in the PCMCIA specification.

       BAD_ARG_LENGTH              ArgLength value
                                   is not equal to
                                   4.

       UNSUPPORTED_MODE            Requested
                                   processor mode
                                   is not 16:16
                                   protect mode.

   o   AdjustResourceInfo (35H)

       The following Attributes are not supported.

       -   For a System Mappable Memory Range, the
           Shared bit is not supported and must be
           reset to 0.

       -   For a System Mappable I/O Range, the
           Shared bit is not supported and must be
           reset to 0.

       -   For a System Steerable IRQ, the
           Time-Multiple Shared bit is not
           supported and must be reset to 0.

       If any of the unsupported Attributes field
       bits are set, the request will fail with a
       BAD_ATTRIBUTE return code.

       Return Codes:

       OS/2 Card Services returns the following
       error codes in addition to the error codes
       defined in the PCMCIA specification.

       BAD_ARGS                    The IOAddrLines
                                   field is 0 or
                                   greater than
                                   16.

   o   GetCardServicesInfo (0BH)

       Card Services returns 0000H for the
       Revision value.

       Card Services returns 0200H for the CSLevel
       value.

       Card Services returns the following text
       for the VendorStrings value:

         IBM OS/2 PCMCIA Card Services Device Driver.
         (C) Copyright IBM Corporation 1992.
         All Rights Reserved.

   o   RegisterClient (10H)

       Card Services does not support the Memory
       Technology Driver bit in the Attributes
       field. If this bit is set to 1, the request
       will fail with a BAD_ATTRIBUTE return code.

       Card Services does not support the Power
       Management Change bit in the EventMask
       field. It is recommended that bit 8 be
       reset to 0 for future compatibility.  Card
       Services ignores the value of bit 8.

       Card Services does not support the Write
       Protect Change bit in the EventMask field.
       It is recommended that bit 0 be reset to 0
       for future compatibility.  Card Services
       ignores the value of bit 0.

       Card Services does not support the Version
       field. It is recommended that the value be
       set to 0200H for future compatibility.
       Card Services ignores the value of the
       Version field.

       Return Codes:

       OS/2 Card Services returns the following
       error codes in addition to the error codes
       defined in the PCMCIA specification.

       BAD_ATTRIBUTE               No client type,
                                   more than one
                                   client type, or
                                   MTD client type
                                   specified.

   o   RequestIO (1FH)

       Card Services does not support the Share,
       First Share, and Force Alias bits in the
       Attributes field. If any of these bits are
       set, the request will fail with a
       BAD_ATTRIBUTE return code.

   o   RequestIRQ (20H)

       Card Services supports the following
       Attributes field bit definitions.

         For ISA bus systems:

            Bit 0 - 1   IRQ type
                        0 - Exclusive
                        1 - Time-Multiplexed Sharing
                            (This value is not supported)
                        2 - Dynamic Sharing
                            (This value is not supported)
                        3 - Reserved

            Bit 2       Force Pulse (Set=True)
            Bit 3       First Shared (Not supported, must = 0)
            Bit 4 - 7   Reserved (Must = 0)
            Bit 8       Pulse IRQ Allocated (Not supported, always returned as 0)
            Bit 9 - 15  Reserved (Must = 0)

         For Micro Channel* bus systems:

            Bit 0 - 1   IRQ type
                        0 - Exclusive
                            (This value is not supported)
                        1 - Time-Multiplexed Sharing
                        2 - Dynamic Sharing
                        3 - Reserved
            Bit 2       Force Pulse (Not supported, must = 0)
            Bit 3       First Shared
            Bit 4 - 7   Reserved (Must = 0)
            Bit 8       Pulse IRQ Allocated
                        (Not supported, always returned as 0)
            Bit 9 - 15  Reserved (Must = 0)

       If any of the unsupported Attributes field
       bits are set, the request will fail with a
       BAD_ATTRIBUTE return code.

   o   RequestSocketMask (22H)

       Card Services does not support the Power
       Management Change bit in the EventMask
       field. It is recommended to reset the bit
       to 0 for future compatibility. Card
       Services ignores the value of the Power
       Management Change bit.

   o   RequestWindow (21H)

       Card Services supports the following
       Attributes field bit definitions.

            Bit 0      Reset to 0.
            Bit 1      Memory type (Set = attribute)
            Bit 2      Enabled (Set = true, reset = disabled)
                       Disabled is not supported, must be set to true.
            Bit 3      Data path width (Reset = 8-bit, set = 16-bit)

            Bit 4      Paged (Set = true)
                       Not supported, must be 0.
            Bit 5      Shared (Set = true)
                       Not supported, must be 0.
            Bit 6      First Shared (Set = true)
                       Not supported, must be 0.

            Bit 7 - 15 RESERVED (reset to 0)

       If any of the unsupported Attributes field
       bits are set, the request will fail with a
       BAD_ATTRIBUTE return code.

       Card Services sets the PCMCIA card memory
       offset for the window to 0.  A client can
       change a PCMCIA card memory offset for the
       window by using the MapMemPage function.

   o   SetEventMask (31H)

       Card Services does not support the Power
       Management Change event bit in the
       EventMask field. It is recommended to reset
       the bit to 0 for future compatibility. Card
       Services ignores the value of the Power
       Management Change bit.


NOTICES
_______

   References in this publication to IBM products,
   programs, or services do not imply that IBM
   intends to make these available in all
   countries in which IBM operates.  Any reference
   to an IBM product, program or service is not
   intended to state or imply that only IBM's
   product, program, or service may be used.  Any
   functionally equivalent product, program, or
   service that does not infringe any of IBM's
   intellectual property rights or other legally
   protectible rights may be used instead of the
   IBM product, program, or service.  Evaluation
   and verification of operation in conjunction
   with other products, programs, or services,
   except those expressly designated by IBM, are
   the user's responsibility.

   IBM may have patents or pending patent
   applications covering subject matter in this
   document.  The furnishing of this document does
   not give you any license to these patents.  You
   can send license inquiries, in writing, to the
   IBM Director of Commercial Relations, IBM
   Corporation, Purchase, NY 10577.


TRADEMARKS AND SERVICE MARKS

   The following terms, denoted by an asterisk
   (*), used in this publication, are trademarks
   or service marks of the IBM Corporation in the
   United States or other countries:

   IBM      Micro Channel
   OS/2     WIN-OS/2


DISCLAIMER AND COPYRIGHT NOTICE

   IBM DISCLAIMS ALL WARRANTIES, WHETHER EXPRESSED
   OR IMPLIED, INCLUDING WITHOUT LIMITATION,
   WARRANTIES OF FITNESS AND MERCHANTABILITY WITH
   RESPECT TO THE INFORMATION IN THIS DOCUMENT.
   BY FURNISHING THIS DOCUMENT, IBM GRANTS NO
   LICENSES TO ANY RELATED PATENTS OR COPYRIGHTS.

   Copyright IBM Corporation, 1992, all rights
   reserved.

